1. Field of the Invention
The present invention relates to client computers that are bootable over a network and, in particular, client computers that may attempt to boot in competition with other client computers. More specifically, the present invention relates to a method for evaluating one or more target devices and their network environment and booting one or more target devices accordingly.
2. Description of the Related Art
Some current computing devices include support for pre-boot extensions to download an operating system (OS) from a network to which they are attached. Such target computing devices include computer motherboards, network adapters and boot diskettes.
These devices may rely on extensions to the bootstrap protocol (BOOTP) and to the dynamic host configuration protocol (DHCP). Such extensions are often termed the preboot execution environment (PXE) and require a DHCP/PXE server and a boot image negotiation layer (BINL) server. Alternatively, these devices may use a feature such as the Remote Program Load (RPL) feature to gain access to the network and request an operating system and other applications. The RPL feature enables the target device to request a bootstrap from another device with a disk drive (the loading device) within the network. The RPL feature also allows the loading device to send the bootstrap to the target device. This loading device may be, for example, a server or another suitable loading device.
With the use of a PXE system or the RPL feature, occasionally a number of target machines may attempt to boot from the network (e.g., from a server or from a loading device) at the same time. In some instances, one or more target machines do not receive the requested bootstrap before ROM on the target machines causes a time out. Such target machines then require a manual reset to cause the boot sequence to re-start on the target machine.
BOOTP is a transmission control protocol/Internet protocol (TCP/IP) used by a diskless workstation, network computer (NC) or other target device to obtain its IP address and other network information, such as server address and default gateway. Upon startup, the target device sends out a BOOTP request to the BOOTP server, which returns the required information. The BOOTP request and response use an IP broadcast function, which is able to send messages before a specific IP address for a target device is known.
DHCP is software that automatically assigns an IP address to a target device logging onto a TCP/IP network. DHCP eliminates the need for manually assigning permanent IP addresses.
PXE enables a client network computer or other target device that lacks a native operating system to locate and acquire a small network bootstrap program (NBP) from a BINL server. The target device may acquire this NBP from a BINL server through a network attachment. PXE also provides a means for running the NPB on the target device. This allows the target device to continue acquiring additional software from the network that may be required to make the target device capable of performing the more complex and useful tasks assigned to it by an enterprise.
PXE relies on extensions of DHCP as the means by which the target device locates a BINL server from which to acquire an NPB. A facilitating property of DHCP is that the target device does not need the address of any other computer. The target device performs a DHCP broadcast to discover any PXE proxy server that can recognize that the target device is PXE-capable. The DHCP proxy server sends a DHCP offer to the target device. The offer contains the address of the BINL server from which the target device may obtain a NBP. The target device then obtains the NBP and all necessary software from the boot server via a trivial file transfer protocol (TFTP).
RPL enables a client network computer or other target device that lacks a native operating system to locate and acquire a bootstrap program (NBP) from a loading device. The target device may acquire this NBP from the loading device through a network attachment. RPL also provides a means for running the NPB on the target device. This allows the target device to continue acquiring additional software from the loading device that may be required to make the target device capable of performing the more complex and useful tasks assigned to it by an enterprise.
RPL generally relies on two programs. These programs are a bootstrap program and a loader program. The bootstrap program is sent by the loading device to one or more target devices. After being installed in the target device, the bootstrap program initializes and restarts the target device. The bootstrap program may be a complete operating system, a program that requests files, a program that requests other programs or any suitable combination of the above.
The loader program sends the bootstrap program to the target device in response to a load request from the target device. The target device may have a RPLBOOT.COM program, which marks the fixed disk in the target device as non-bootable so that the RPL feature can take control when the target device is started.
Whether the target machine relies on PXE and a PXE server or RPL and an RPL loading device to receive its bootstrap, occasionally, the network traffic may be so heavy that the target machine's boot request is ignored and the target machine times out. This may occur, for example, due to heavy network or server load in a boot-storm environment, such as after a power failure and restore, when a number of target devices attempt to boot at the same time.
Alternatively, a target machine's boot request may be acknowledged but due to time outs of network file in and file out requests that occur as the boot sequence is being implemented, the target machine still times out.
In such situations, the resources of the network may be severely overloaded and target machines suffer because there are not enough resources available to boot a given machine.
Target machines that time out in this manner require a manual reset. This may be problematic in a server-managed environment because the timed-out target device may no longer be controlled from the server or any other device on the network. Rather, an actual person must manually reset the target device. Thus, current approaches to booting a target device in the presence of network delays may require a manual reset.
It would be desirable therefore to provide a method of booting a target device in a network environment that overcomes the above.